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ABSTRACT 

In  this  paper,  we  provide  the  background  to  counterfactual 
logic  and  give  very  general  suggestions  on  how  we  could 
employ  this  logic  to  help  us  reason  about  security  policies.  It 
seems  very  appropriate  to  use  this  kind  of  logic  to  anticipate 
a  change  that  will  compromise  the  security  concerns  of  a 
given  system  before  actually  applying  the  changes. 

Categories  and  Subject  Descriptors 

F.3.1  [Logics  and  Meaning  of  Programs]:  Specifying 
and  Verifying  and  Reasoning  about  Programs — logic  of  pro¬ 
grams',  D.4.6  [Operating  Systems]:  Security  and  Protec¬ 
tion — access  controls 

General  Terms 

Formal  Verification,  Security 

Keywords 

formal  verification;  proof  theory;  security  models;  software 
engineering 

1.  INTRODUCTION 

In  the  realm  of  software  security,  changes  regarding  secu¬ 
rity  policies  are  pervasive.  It  is  in  this  constant  changing  en¬ 
vironment  where  a  system’s  security  becomes  compromised. 
In  practice,  security  policies  are  changed  and,  in  the  worst 
case,  any  defect  or  undesired  effect  is  usually  found  after  the 
fact  and  often  too  late.  Requiring  that  the  security  policies 
remain  unchanged  is  out  of  the  question  and  blatantly  unre¬ 
alistic.  Therefore,  we  are  in  need  of  mechanisms  that  enable 
us  to  formalize  the  security  policies,  the  changes  regarding 
security  policies  and  the  future  effect  of  said  changes. 

In  this  paper  we  present  a  framework  for  what-if  analysis 
of  security  policies  based  on  Lewis’  theory  of  counterfactuals 
[7].  The  framework  can  be  used  to  statically  perform  change- 
impact  analysis  for  access  control  matrices.  It  enables  us  to 
verify  assertions  about  a  changed  version  of  an  access  con¬ 
trol  matrix  without  actually  incorporating  the  changes.  We 
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present  a  logical  calculus  that  precisely  characterizes  poten¬ 
tial  structural  modifications  to  source  code  and  their  impact 
on  the  program’s  behavior. 

2.  RELATED  WORK 

The  theory  of  counterfactuals  allows  us  to  reason  about 
hypothetical  situations.  It  has  been  used  in  Philosophy  and 
Political  Science  [9]  for  decision  making  in  a  hypothetical  en¬ 
vironment.  In  Physics,  it  has  been  used  for  reasoning  about 
measurements  in  quantum  mechanics  [12],  [8].  The  main 
idea  exposed  by  Fisler  et  al.  in  [2]  is  to  gain  knowledge  re¬ 
garding  the  effects  of  changing  access  control  policies  before 
actually  making  such  changes.  The  work  of  Fisler  et  al.  Is 
similar  to  the  one  presented  in  this  paper  as  it  tries  to  find 
the  effects  of  a  change  a  priori.  The  work  of  Chockler  et  al. 
in  [1]  employs  counterfactual  reasoning  also  in  the  context 
of  model  checking.  In  this  instance,  the  authors  emphasize 
their  work  in  coverage  issues.  They  use  counterfactual  rea¬ 
soning  to  enhance  the  coverage  information.  This  work  dif¬ 
fers  from  ours  since  they  use  counterfactual  logic  to  explore 
alternative  scenarios  whereas  we  explore  a  single  alternative 
version  given  an  initial  version. 

Also,  in  [4],  Groce  et  al.  use  counterfactual  theory  to  de¬ 
tect  failures,  isolate  errors  and  aid  in  repairing  modifications 
of  program  code  in  the  context  of  model  checking.  They  con¬ 
struct  a  model  of  program  executions  and  establish  a  metric 
among  them.  This  metric  lets  them  analyze  faulty  execu¬ 
tions  by  examining  those  which  lie  at  some  distance  from  a 
given  faulty  execution.  The  work  of  [4]  relates  to  ours  in  the 
sense  that  the  authors  define  a  notion  of  distance  among  pos¬ 
sible  execution  traces  in  the  same  sense  we  implicitly  define 
the  number  of  transformation  steps  between  program  ver¬ 
sions.  In  [4] ,  however,  the  authors  go  beyond  just  defining  a 
notion  of  proximity  and  actually  define,  given  a  system  exe¬ 
cution  trace,  the  set  of  neighboring  traces  whereas  our  work 
only  characterizes  a  single  future  version.  The  work  of  Ren 
et  al.  in  [11]  exposes  a  tool  (i.e.  Chianti)  that  analyzes  two 
different  versions  of  a  given  program  and  a  set  of  test  cases 
for  such  program  and  determines  which  tests  are  affected 
due  to  the  changes  that  lead  from  one  version  to  another. 
Furthermore,  for  each  affected  test,  the  tool  determines  a 
set  of  method-level  changes  that  most  probably  affected  the 
test.  Our  work  differs  from  the  work  in  [11]  in  the  sense 
that  we  do  not  require  a  second  version  and  a  set  of  test 
cases.  Our  approach  just  needs  the  changes  to  be  expressed 
in  our  logical  calculus.  The  approach  given  by  Guo  et  al. 
in  [5]  exhibits  a  method  by  which  change  impact  analysis  is 
modeled  and  verified  in  a  distributed  setting.  Their  model  is 
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in  essence  a  network  of  state  machines  that  communicate  ei¬ 
ther  via  shared  variables  or  queues.  Changes  are  modeled  as 
adding  and/or  deleting  transitions  from  the  composite  state 
machine  that  represents  the  distributed  system.  The  work 
in  [5]  is  similar  to  ours  in  the  context  of  two  aspects:  1)  the 
authors  are  formally  representing  change  in  a  system,  how¬ 
ever,  their  approach  targets  distributed  computations  and  is 
based  on  model  checking  whereas  our  approach  targets  se¬ 
quential  computation  and  it  is  based  on  theorem  proving;  2) 
this  approach  prunes  the  global  state  space  by  using  partial 
order  reduction  in  order  to  infer  the  valid  transitions  when  a 
change  occurs;  our  approach  deals  with  change  at  the  source 
code  level  and  the  validity  of  the  change  is  inferred  by  our 
logical  calculus. 

In  [13],  Subramaniam  et  al.  enhance  the  approach  shown 
in  [5].  The  changes  are  still  represented  by  adding  and/or 
deleting  transitions  of  a  composite  state  machine.  However, 
this  work  addresses  the  issue  of  test  suite  coverage  when 
changes  occur.  This  approach  detects  the  affected  tests 
based  on  whether  or  not  these  include  the  affected  tran¬ 
sitions.  Using  formal  verification  techniques  similar  to  the 
ones  presented  in  [5],  the  authors  are  able  to  reduce  the  total 
regression  test  suite  by  identifying  which  tests  are  relevant 
after  a  given  change.  Our  approach  goes  in  a  different  di¬ 
rection  by  formally  characterizing  the  source  code-change 
and  determining  if  the  changes  to  the  current  source  code 
version  are  logically  consistent  with  its  properties  and  the 
future  desired  properties. 

The  work  presented  in  [10]  uses  symbolic  execution  to  es¬ 
tablish  whether  or  not  two  source  code  versions  are  equiv¬ 
alent.  In  the  negative  case  the  proposed  approach  gener¬ 
ates  the  deltas  which  characterize  the  input  values  that  in¬ 
duce  the  behavior  difference  between  the  two  versions.  Our 
approach,  being  based  on  proof-theoretic  methods,  relies 
mostly  on  the  syntactic  nature  of  change  and  hence  we  con¬ 
sider  two  versions  identical  as  long  as  they  have  equivalent 
logical  characterizations.  The  latter  also  means  that  we  are 
only  interested  on  cases  where  our  two  versions  (the  actual 
and  the  potential  version)  are  logically  different. 

3.  COUNTERFACTUAL  THEORY 

The  logic  of  counterfactuals  helps  us  reason  about  asser¬ 
tions  that  are  not  a  matter  of  fact.  In  [7]  Lewis  provided  a 
sound  and  complete  proof  system  and  proved  its  decidabil¬ 
ity.  Based  on  the  logic  of  counterfactuals  we  derive  a  logical 
calculus  that  allows  us  to  assert  properties  that  would  hold 
for  a  future  version  of  a  given  program  and  verify  that  these 
would  indeed  hold  if  the  changes  needed  to  obtain  that  ver¬ 
sion  were  actually  implemented. 

3.1  The  Language  of  Counterfactual  Theory 

In  coherence  with  [7]  we  will  briefly  introduce  the  language 
regarding  the  logic  of  counterfactuals  below  (pi  denotes  a 
propositional  variable): 

4>  ::=  pi[-'(/[/>  A  (f)\4>  V  (f)\4>  (f>\4>  </ 

The  counterfactual  sentence  (j>  □->  tp  should  be  read  as:  if 
it  had  been  the  case  that  (f>,  it  would  have  been  the 
case  that  ip.  Thus,  if  we  had  an  assertion  whose  antecedent 
ranged  over  the  properties  of  some  given  access  control  ma¬ 
trix  and  also  the  changes  needed  to  produce  a  new  version 
and  whose  consequent  ranged  over  the  properties  that  a  new 


version  would  have,  then  we  could  use  counterfactual  logic 
to  code  such  an  assertion. 

3.2  F ormal  Representation  of  A  Security  Model 

In  this  section  we  will  define  a  simple  variation  of  the  Ac¬ 
cess  Control  Matrix  (ACM)  model.  This  model  was  first 
introduced  in  [6]  and  [3].  We  have  chosen  this  model  due 
to  its  simplicity  and  readily  intuitive  nature  and  widespread 
use  as  it  is  stated  in  [6[.  First  of  all,  we  will  define  three 
sets:  S,  O  and  A  which  are  respectively  the  set  of  :  sub¬ 
jects,  objects  and  actions.  The  set  of  subjects  contains  the 
active  entities  on  the  system  (i.e.  users,  computer  systems, 
etc.);  the  set  of  objects  denotes  the  set  of  entities  over  which 
subject  are  allowed  or  denied  a  certain  action.  The  set  of 
actions  denotes  those  tasks  which  a  subject  can  perform  on 
a  given  object.  Hence: 

S  =  {si}iei  The  set  of  subjects 

O  =  {oj}jej  The  set  of  objects 

A  =  {Read,  Write}  The  set  of  actions 

Thus,  we  can  now  formally  define  an  access  control  matrix 
as  a  function  M  :  S  x  O  — >■  2'^  which  takes  an  ordered  pair 
composed  of  a  subject  and  an  object  and  assigns  to  them 
a  subset  of  the  possible  set  of  actions.  Moreover,  in  this 
instance  we  will  have  to  work  with  M’s  intentional  or  set 
representation  and  thence: 

M  =  {{si,Oj,ak)}  where  Ok  €  2^ 

3.2.1  Encoding  Change  in  the  ACM  model 

Let  M  =  {{si,Oj,  ak)i,j,ken}  be  the  current  version  of  the 
access  control  matrix.  We  can  encode  the  state  of  any  ACM 
by  using  the  following  formula: 

n  m  p 

'Fm  =  A  A  /\{si,Oj,ak)&M 

i=l j=l k=l 

We  will  simplify  the  latter  expression  using  the  following 
notation: 

=  A  isi,Oj,ak) 

For  the  sake  of  simplicity  we  will  define  a  change  to  the 
ACM  as  a  change  to  the  members  of  the  action-set  of  a  given 
triple.  Hence,  a  change  may  be  represented  as: 

i.Si,Oj,eXk)  ^ 

It  can  be  readily  inferred  that  is  a  three-place-relation 
over  S  X  O  X  A.  Furthermore,  let  M  denote  the  class  of  all 
possible  ACM  versions.  Therefore,  can  be  thought  of  as 
a  binary  relation  over  M  and 

M  M'  iff  M'  =  M[ak/ak] 

Moreover  we  dehne  to  be  the  smallest  relation  such 
that  the  following  holds: 

,cxkP)  iff: 

1.  a'k  yf  0  when  afc  /  0 

2.  a'k  yf  A  when  au  =  A 
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3.2.2  Undesirable  Configurations 

In  any  system,  there  is  a  set  of  undesirable  states.  These 
states  may  be  very  possibly  members  of  the  entire  set  of  pos¬ 
sible  states.  One  of  the  fundamental  purposes  of  any  security 
mechanisms  is  to  guarantee  that  for  any  possible  transition 
(that  originates  in  a  safe/legal  state)  the  target  state  will 
not  be  an  illegal/undesirable  state.  In  this  instance  an  un¬ 
desired  state  will  be  denoted  by  a  given  configuration/triple 
of  subject,  object  and  action.  Therefore,  let  ?7  (-  S  x  O  x  A 
be  the  set  of  illegal  configurations  and  let  r„  range  over  this 
set. 

We  want  to  avoid  allowing  a  configuration  change  in  which 
we  enable  an  undesirable  triple  be  part  of  the  new  version 
of  the  ACM.  Hence,  we  want  to  avoid  the  following: 

M  M'  where  Tu  G  M' 

3.2.3  Secure  Counterfactual  Change 

Our  objective  is  to  enable  counterfactual  logic  to  let  us 
decide  whether  or  not  a  change  to  the  current  version  of  the 
ACM  implies  that  at  least  one  illegal  triple  is  part  of  the 
future  resulting  version.  Thence  our  secure  counterfactual 
implication  can  be  expressed  as: 

[  f\  {si,Oj,ak)]/\{so,OQ,ao)\ac/aQ\cH>  M') 

3.3  Kripke  Versioning  Model 

In  [7]  the  author  provides  the  semantics  of  his  counter- 
factual  propositional  logic  using  a  multiple-world  interpre¬ 
tation.  In  that  same  manner  we  have  chosen  to  interpret 
our  access  control  matrix  transformation.  In  our  case,  each 
ACM  version  will  represent  a  world.  In  the  following  defi¬ 
nition,  we  take  the  liberty  of  writing  ti  tj  to  denote  that 
the  tuple  ti  was  swapped  by  tuple  tj.  Below,  we  provide  a 
formal  interpretation  based  on  a  Kripke  model. 

Definition  3.1  (Kripke  Version  Model).  A  Kripke 
Version  Model  TZ  is  a  triple  (A4,=i>,Mo)  where: 

1.  Ai  =  {Mk}k€N  is  the  set  of  all  access  control  matrix 
versions  (ACM  states). 

2.  Mo  is  the  initial  access  control  matrix. 

3.  M  X  M  is  a  binary  relation  defined  the  set  of 
all  possible  ACM  versions.  Where  =>  is  the  smallest 
relation  such  that  the  following  properties  hold: 

(a)  ti  ■(—  ti  :  tuple  Si  is  left  unchanged.  This  stands 
for  the  do  nothing  transformation. 

(b)  ti  <—  tj  :  tuple  tj  replaces  statement  ti,  where 
tj  G  Mk-  We  usually  call  this  primitive  transfor¬ 
mation,  a  swap. 

(c)  ti  tj  :  statement  tj  replaces  statement  ti,  where 
tj  ^  Mk.  Thus,  Sk  is  a  new  statement. 

(d)  (yi)ti  G  Mk  can  be  changed  only  once. 

Furthermore,  we  assume  that  the  relation  complies 
with  the  properties  of  reflexivity,  symmetry,  and  transitivity. 
Below,  we  justify  each  property  based  on  the  latter  definition 
of 


1.  Reflexivity:  For  any  ACM  Mi  G  A4,  it  is  obvious 
that  the  do-nothing  transformation  will  yield  that  any 
ACM  can  be  transformed  into  itself.  Therefore,  Mi  => 
Mi  given  that  for  all  Sj  G  Mi,  Mi  =  Mi[sj/sj] 

2.  Symmetry:  For  any  ACMs  Mi,Mj  G  Ai  any  of  the 
above  transformations  can  be  reversed  and  therefore. 
Mi  =>  Mj  implies  Mj  =>  Mi. 

3.  Transitivity:  For  any  ACMs  Mi,  Mj ,  Mk  G  AA,  ap¬ 
plying  two  or  more  transformations  to  a  program  will 
yield  intermediate  versions;  this  is  equivalent  to  trans¬ 
forming  the  initial  version  by  composing  the  transfor¬ 
mations  into  one.  Thus,  Mi  =>  Mj  and  Mj  =>  Mk  im¬ 
ply  that  Mi  =>+  Mk.  Where  denotes  o 

and  n  >  1. 

3.4  Interpreting  the  Counterfactual  Implica¬ 
tion 

As  it  was  stated  earlier,  the  purpose  of  our  model  is  to  help 
interpret  assertions  in  the  language  of  counterfactual  logic. 
Let  Mo  denote  our  given  initial  ACM  version.  Also,  let  us 
assume  we  had  a  counterfactual  assertion,  namely  (j)  □->  ip 
in  which: 

•  (j>  stands  for  assertions  regarding  Mo  and  some  trans¬ 
formation  ti  -c-  tj  that  implies  that  Mi  =  Mo[ti/tj] 

•  Ip  stands  for  assertions  regarding  Mi 

Thus,  following  the  model-theoretic  interpretation  pro¬ 
posed  by  Lewis  in  [7],  our  version  of  the  counterfactual  im¬ 
plication  is  interpreted  as: 

TZ  \=  (p  .  (1) 

Where  TZ  denotes  our  previously  defined  Kripke  Version¬ 
ing  Model.  Moreover,  letting  ai,pii  denote  propositional 
statements  about  the  structure  of  Mi  and  Mj  respectively, 
then,  we  can  state  that: 

n 

4>  =  {/\ai)A{Mi=^+Mj) 

i=l 

m 

-  /\Pj 

j=i 

Where  denotes  the  positive/transtive  closure  for  the 
relation  Furthermore,  given  an  initial  ACM  version, 
namely  Mo,  we  produce  several  versions  by  applying  one 
or  more  transformations  to  it.  In  the  context  of  a  coun¬ 
terfactual  assertion,  the  current  version’s  structure  and  the 
changes  applied  to  it  (in  order  to  produce  a  new  version) 
imply  properties  possessed  the  new  version  and  hence: 

TZ(=<pr^i^  ^  (3minfcGN)(Ar=iai) 

A(Mo^''M')^(Ar=ift)  • 

The  latter  should  be  interpreted  as  there  exists  a  min¬ 
imal  number  of  transformation  steps  such  that  given  the 
properties  of  our  initial  ACM  Mo  (namely,  AILi 
transformation  between  the  two  program  versions  implies 
the  desired  properties  of  the  future  ACM  version  (namely. 
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4.  APPLICATIONS  OF  COUNTERFACTUAL 
THEORY  TO  SECURITY 

Each  change  to  the  access  control  matrix  modifies  the 
state  of  the  security  system.  Hence,  each  change  reflects 
a  change  in  the  set  of  valid  policies.  It  seems  very  promising 
to  use  counterfactual  logic  to  1)  encode  the  changes  to  the 
ACM,  2)  express  the  undesirable  state-tuples,  and  3)  assert 
whether  or  not  the  changes  counterfactually  imply  the  unde¬ 
sirable  tuples  are  part  of  the  future  state  of  the  ACM.  Given 
all  the  risks  involved  in  changing  security  policies,  it  would 
be  nice  to  foresee  their  effect  before  incorporating  them  into 
production  systems. 

5.  CONCLUSION  AND  FUTURE  WORK 

We  have  introduced  a  logical  calculus  based  on  Lewis’  the¬ 
ory  of  counterfactuals.  Additionally  we  have  shown  that  if 
we  know  how  to  unambiguously  characterize  the  transforma¬ 
tion  from  the  initial  ACM  state  to  the  future  desired  ACM 
state,  the  conjunction  between  the  structural  properties  of 
the  initial  ACM  version  and  the  predicates  that  character¬ 
ize  the  transformation,  imply  the  desired  future  ACM  state’s 
properties. 

This  position  paper  has  presented  a  powerful  and  promis¬ 
ing  suggestion  which  consists  of  jointly  using  a  perhaps  mod¬ 
ified  version  of  the  ACM  model  and  our  counterfactual  logi¬ 
cal  calculus.  The  latter  mix  would  enable  practitioners  ver¬ 
ify  a-priory  the  effects  of  a  change  to  the  ACM  without 
actually  applying  the  change  to  production  systems.  Al¬ 
though  it  is  widely  known  that  the  question  of  whether  or 
not  a  given  security  model  enforces  a  given  policy  is  a  non- 
decidable  problem,  we  are  confident  that  our  simplified  ACM 
model  and  our  counterfactual  logic  will  be  helpful  to  enough 
non-trivial  applications. 
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